1. Statement of the Technical Field
The present invention relates to the field of autonomic computing, and more particularly to resource monitoring to autonomically manage resources processing computing workloads.
2. Description of the Related Art
Among the many challenges faced by those who manage the capacity and performance of an enterprise system is the characterization of computer system and network resource consumption by a particular application or workload. The continuing movement towards distributed systems has complicated this activity as there are several methods for collecting transaction data on a single system: For instance, a transaction processing monitor can be configured to capture some form of resource consumption data. Similarly, some database management systems provide facilities for capturing transaction activity within the context of each access request.
Facilities within a particular operating system also may have a built-in notion of what a transaction is and will store or report information related to that transaction. Furthermore, applications developers can imbed instrumentation within application code in order to obtain transaction specific data. Finally, application profilers for a particular operating environment can gather large amounts of data relating to the behavior of an application hosted within the operating environment. In all cases, however, when applied to the distributed environment, it can be difficult to track resource consumption by a transaction when several elements in a network contribute towards the completion of a transaction
Recently, several computing vendors have collaborated to develop an open, vendor-neutral approach to manage the performance of distributed applications. The Application Response Measurement (ARM) interface, is an application programming interface (API) for measuring end-to-end application response time. The ARM API allows vendors to create management-ready applications and it allows end users to measure and control the total performance of their business-critical distributed applications.
The ARM API is a simple API that applications can use to pass vital information about a transaction to an agent. Specifically, to monitor the progress of a transaction, an application need only call the ARM API just prior to the start of the transaction and again before the completion of the transaction. Consequently, the ARM API calls can be used to identify the application, the transaction, and optionally the user, and provide the status of each transaction when it completes. This is sufficient information for the management solution to answer vital questions regarding the operation and performance of the computing system hosting the workload.
Whereas optimally configuring a virtual log can be problematic generally for who manage the capacity and performance of an enterprise system, in an autonomic system, the problem can be particularly acute. For the uninitiated, autonomic computing systems self-regulate, self-repair and respond to changing conditions, without requiring any conscious effort on the part of the computing system operator. To that end, the computing system itself can bear the responsibility of coping with its own complexity. The crux of autonomic computing relates to eight principal characteristics:
I. The system must “know itself” and include those system components which also possess a system identity.
II. The system must be able to configure and reconfigure itself under varying and unpredictable conditions.
III. The system must never settle for the status quo and the system must always look for ways to optimize its workings.
IV. The system must be self-healing and capable of recovering from routine and extraordinary events that might cause some of its parts to malfunction.
V. The system must be an expert in self-protection.
VI. The system must know its environment and the context surrounding its activity, and act accordingly.
VII. The system must adhere to open standards.
VIII. The system must anticipate the optimized resources needed while keeping its complexity hidden from the user.
In an on demand computing environment, the role of a host computing device and the workload processed in the host can vary based upon business need, the point-in-time when the workload is processed, the volume of different workloads experienced at that time, and the relative priorities of those workloads. A change in demand for specific applications can result in the re-provisioning of a host computing device that had previously served requests for a particular workload, into a different role hosting different applications.
Accordingly, understanding that a change has transpired, and identifying the new role of the host computing device can be fundamental to correctly optimize the usage of the host computing device. Examples include the active monitoring of the health and of the performance of the applications active within the host computing device. Knowing the role of the host computing device can affect the monitoring policy applied to the host computing device. For instance, while a host computing device may support the operation of a database management system, the use of the database management system can change from supporting real-time transactions to mere batch transactions. Clearly, the monitoring policy for a database supporting real-time transactions will differ from the monitoring policy for a database supporting only batch transactions, if only to disable interactive response time-related sensors.